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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

In re Application of: Rodney G. Adams Examiner: Meky, Moustafa 

Serial No. 09/357,250 Art Unit: 21 57 

Filed: 07/20/1999 

For: SYSTEM AND METHOD FOR TRANSFERRING INFORMATION IN A 
HYPERTEXT TRANSFER PROTOCOL BASED SYSTEM 

Mail Stop AF 
Commissioner for Patents 
PO Box 1450 

Alexandria, VA 22313-1450 
Sir: 

PRE-APPEAL BRIEF REQUEST FOR REVIEW 

The current remarks provide the succinct, concise, and focused set of arguments for 
which the review is being requested and accompany the concurrently filed Notice of Appeal. 
Applicant hereby authorizes the $500.00 cost of the Notice of Appeal to be charged to Deposit 
Account 50-0873. If any additional fees are required in association with this response, the 
Director is hereby authorized to charge them to Deposit Account 50-0873, and consider this a 
petition therefor. 
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REMARKS 

Applicant files the Request for a Pre- Appeal Brief Review of the application so that the 
panel of Examiners may determine whether the Office Actions of record adequately establish 
that U.S. Patent No. 6,594,699 to Sahai et al, ("Sahai") anticipates claims 1, 2, 4-10, 12-20, and 
22-24 of the present application under 35 U.S.C. § 1 02(e). 1 In particular, Applicant queries 
whether the Patent Office has established a prima facie case of anticipation since the reference of 
record does not teach or suggest " creating a plurality of state objects at the HTTP client" or 
"storing the plurality of State objects on the HTTP client prior to an initial interaction with the 
HTTP server" as recited in the claims. 

The Patent Office Has Not Established That Every Element of the Claim is Taught 

It is clear law that in order to anticipate a claim, the prior art reference must teach every 
element of the claim, MPEP §2131. Therefore, to sustain this rejection, Sahai must contain all 
of the claimed elements of claims 1 , 2, 4-1 0, 1 2-20, and 22-24. 

1. Sahai Does Not Teach Creating a Plurality of State Objects at the HTTP Client 

Claim 1 recites, in part: " creating a plurality of state objects at the HTTP client." 
(emphasis added). The Examiner argues that this limitation is found in Sahai at column 3, lines 
64-67. The cited portion of Sahai states "[T]he client capability is specified in a flat file which 
resides on the client machine 12 and which is maintained in the client system and by the system 
administrator (or user) or by a graphical user interface." Applicant submits this cited portion of 
the reference simply does not teach " creating a plurality of state objects at the HTTP client." 
The Examiner attempts to equate "client's capabilities and user preferences" with the state 
objects as recited in the claim. Initially, applicant notes that the cited portion of the Sahai 
reference does not discuss user preferences at all, but merely discusses the client capability being 
specified in a flat file which resides on the client machine. In any event, the reference does not 
teach creating anything at the HTTP client and the client capability found in the flat file certainly 
is not the same as the state objects claimed in claim 1 . 

The client capabilities of Sahai are not the same as the state objects as claimed in the 
present invention. In the present application, the term v; state objects" (or "cookies") is discussed 

1 Claims 3,11, and 21 have been deemed to be allowable if rewritten in independent form, 

2 
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in the specification (see, e.g., p. 1, line 10 - p. 2, line 19, and p. 5, line 17 - p. 6, line 24) as 
typically including a name attribute, an expiration attribute, a domain attribute, a path attribute, 
and an attribute requesting transmission using a secure channel. The client capabilities discussed 
in Sahai do not include these attributes. Sahai is concerned with the capabilities of a client to 
handle the demands of media-on-demand multimedia streaming data, such as processor speed 
and multimedia encoders. Sahai is not concerned with the state objects, or "cookies," associated 
with transferring information between a HTTP client and a HTTP server, as discussed in the 
present invention. One of ordinary skill in the art would not read the client capabilities of Sahai 
as being the same as the state objects as claimed in the present invention. Thus, Sahai does not 
teach creating a plurality of state objects at the HTTP client, as claimed in claim 1 of the 
present application, and therefore does not anticipate claim 1. Independent claims 7, 15, 16, 17, 
and 18 have similar claim limitations, and are likewise not anticipated by Sahai. 

2. Sahai Does Not Teach That the Plurality of State Objects Be Stored on the HTTP Client 
Prior to an Initial Interaction with the HTTP Server 

Claim 1 also recites that the plurality of state objects be stored on the HTTP client prior 
to an initial interaction with the HTTP server. The Examiner cites column 3, lines 64^67, and 
col. 4, lines 1-3 for this limitation. Column 3, lines 64-67 was set forth above. Col. 4, lines 1-3 
simply add that "[i]f a file is maintained in the client 12, the file needs to be updated any time the 
client capabilities change, such as when a new version of an operating system is installed." 
Applicant fails to see how there is anything in these passages that indicates that anything 2 is 
stored on the HTTP client prior to an initial interaction with the HTTP server. Therefore, this 
limitation has not been proven by the Examiner to be taught by Sahai. 

In the Advisory Action, the Examiner stated that: "The client's state objects are stored on 
the client prior to an initial interaction with the server i.e. these state objects are stored on the 
client before interacting with a server. Also, these state objects could be updated regardless of 
the server i.e. before interacting with the server, see col 3, lines 64-67, col 4, lines 1-3." 
Advisory Action, p. 5, lines 1-4. Applicant has already noted that the cited passage fails to teach 
or even discuss storing anything prior to an initial interaction with the HTTP server. In addition, 



2 Applicant also points out that the state objects, as that term is claimed in the invention, are certainly not stored on 
the HTTP client prior to an initial interaction with the HTTP server. 
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another passage in Sahai 3 (cited by the Examiner in discussing a different element) shows that in 
the Sahai system, the application sent by the server to the client asks the user to supply 
information about the client capabilities and then stores that information on the server. This 
argues against a reading of Sahai as teaching that the state objects are stored on the client prior to 
an initial interaction with the HTTP server and in fact teaches away from the present claimed 
invention. 

In addition, although unclear, the Examiner seems to suggest the claim limitation would 
be met because the state objects could be updated regardless of the server. This is simply false 
and ignores the limitation. Since the claims requires that the state objects be stored on the HTTP 
client prior to an initial interaction with the HTTP server, something being done regardless of the 
server would not meet the limitation. 

In any event, as set out above, Sahai does not teach the limitation of claim 1 of "storing 
the plurality of state objects on the HTTP client prior to an initial interaction with the HTTP 
server/' Claim 7, and the claims that depend from it, have a similar limitation, and are likewise 
not anticipated by Sahai. 

Claims 2-6, 8-14, and claims 1 8-24, depend from and further limit their respective 
independent claims, and are therefore allowable for the same reasons as the independent claims. 

Applicant requests that the panel of Examiners review the arguments previously 
presented and determine whether the Patent Office has established that each and every limitation 
of the claim is shown in the Sahai reference, as is required for anticipation. If the panel 
determines that this requirement has not been met, Applicant requests withdrawal of the rejection 
and claim allowance. 



1 Sec Sahai, col. 6, line 66 through col. 7 t line 7. 
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Date: December 8, 2005 
Nortel Networks 

PO Box 13828, RTP, NC 27709-3828 
Telephone: 919/997-3479 
Facsimile: 919/997-6659 



Respectfully submitted, 

John R. Witcher, III 

Senior IP Counsel, Nortel Networks 

Registration No. 39,877 



CERTIFICATE OF TRANSMISSION 

1 hereby certify thai this document is being transmitted via 
facsimile to 571-273-&300 on December 8, 2005 to; 

Examiner: Moustafa Melcv Art Unit: 2157 

« NameoiSendes • 
^ Signature I U 
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Listing of Claims: 

1 . (Previously Presented) A method of presenting custom information to an HTTP client 
from an HTTP server, the method comprising the steps of: 

creating a plurality of state objects at the HTTP client; 

storing the plurality of state objects on the HTTP client prior to an initial interaction with 
the HTTP server; 

initiating an interaction between the HTTP client and the HTTP server; 
requesting information from the HTTP server; 

sending at least one of the state objects to the HTTP server so that the information can be 
formatted responsive to the sent state object; and 

receiving the formatted information to the HTTP client. 

2. (Previously Presented) The method of claim 1 further comprising the step of: 

selecting the one state object based on the information requested and prior to any 
interaction between the HTTP client and the HTTP server. 

3. (Original) The method of claim 1 further comprising the steps of: 

based on previously requested information, automatically creating a state object by the 
http client; 

storing the automatically created state object on the http client; 

if information on the http server is requested, additionally sending the automatically 
created state object to the http server; and 

based on the automatically created state object, transmitting the information relating to 
the previously requested information to the http client. 

4. (Original) The method of claim 1, wherein the plurality of state objects include at least one 
attribute. 

5. (Original) The method of claim 4 further comprising the step of defining the attributes by a 
user. 
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6. (Original) The method of claim 4 further comprising the steps of: 

creating new attributes by a user; and 
defining the new attributes by the user. 

7. (Previously Presented) A method of transferring state objects between an http client and a 
plurality of http servers, the method comprising the steps of: 

creating a plurality of state objects at the http client; 

storing the plurality of state objects on the http client prior to any interaction with a first 
http server; 

if information on the first http server is requested, sending the plurality of state objects to 
the first http server; 

if information on a second http server is requested, sending the plurality of state objects 
to the second http server; and 

based on the plurality of state objects, transmitting the information to the http client. 

8. (Original) The method of claim 7, wherein the plurality of http servers may be located in a 
single domain. 

9. (Original) The method of claim 7, wherein the plurality of http servers may be located in a 
plurality of domains. 

1 0. (Original) The method of claim 7 further comprising the steps of: 

based on the information requested, sending certain state objects to the plurality of http 
servers; and 

based on the certain state objects, transmitting the information to the http client. 

1 1 . (Original) The method of claim 7 further comprising the steps of: 

based on previously requested information; automatically creating a state object by the 
http client; 

storing the automatically created state object on the http client; 
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if information on the plurality of http servers is requested, additionally sending the 
automatically created state object to the plurality of http servers; and 

based on the automatically created state object, transmitting the information relating to 
the previously requested information to the http client, 

12. (Original) The method of claim 7, wherein the plurality of state objects include at least one 
attribute. 

13. (Original) The method of claim 1 2 further comprising the step of defining the attributes by 
a user. 

14. (Original) The method of claim 12 further comprising the steps of: 

creating new attributes by a user; and 
defining the new attributes by the user. 

1 5 . (Previous ly Presented) A communic ation network comprises: 

a client system having a client processor and a client computer readable medium coupled 
to the client processor, the client computer readable medium containing program instructions for: 
creating a plurality of state objects; 

storing the plurality of state objects independent of an HTTP server; 
requesting information from the HTTP server; 
sending the plurality of state objects to the HTTP server; and 
receiving the information from the HTTP server based on the plurality of state 
objects; and 

a server system having a server processor and a server computer readable medium 
coupled to the server processor, the server system coupled to the client system, the server 
computer readable medium containing program instructions for: 

receiving the request for information from the client system, the request being a 
first interaction between the HTTP server and the HTTP client; 
receiving the plurality of state objects; and 
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transmitting the information to the client system based on the plurality of state 
objects. 

16. (Previously Presented) A computer readable medium on an http client, wherein the 
computer readable medium contains executable program instructions for: 

creating a plurality of state objects at the HTTP client; 

storing the plurality of state objects on the HTTP client independent of an HTTP server; 
requesting information from the HTTP server; 
sending the plurality of state objects to the HTTP server; and 
receiving the information from the HTTP server based on the plurality of state objects. 

1 7. (Previously Presented) A computer readable medium on an HTTP server, wherein the 
computer readable medium contains executable program instructions for: 

receiving a request for information from an HTTP client, the request being a first 
interaction between any HTTP server and the HTTP client; 

receiving, from the HTTP client, a plurality of state objects that were not forwarded by 
any HTTP server to the HTTP client; and 

transmitting the information to the HTTP client based on the plurality of state objects. 

1 8. (Previously Presented) A computer system comprises: 

a processor; 

memory coupled to the processor; and 

a computer readable medium coupled to the processor, wherein the computer readable 
medium includes executable program instructions for: 

creating a plurality of state objects at a client; 

storing the plurality of state objects on the client, independent of a particular 

server; 

if infonnation on a server is requested, sending the plurality of state objects to the 
server; and 

based on the plurality of state objects, transmitting the information to the client. 
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19. (Original) The computer system of claim 18 wherein the plurality of state objects may be 
sent to any server in any domain. 

20. (Original) The computer readable medium of claim 1 8, wherein the executable program 
instructions further: 

based on the information requested, send certain state objects to the server; and 
based on the certain state objects, transmit the information to the client. 

21 . (Original) The computer readable medium of claim 1 8, wherein the executable program 
instructions further: 

based on previously requested information, automatically create a state object by the 

client; 

if information on the server is requested, additionally send the automatically created state 
object to the server; 

based on the automatically created state object, transmit the information relating to the 
previously requested information to the client; and 

store the automatically created state object on the client. 

22. (Original) The computer readable medium of claim 1 8 3 wherein the plurality of state 
objects include at least one attribute. 

23. (Original) The computer readable medium of claim 22, wherein the executable program 
instructions further allow a user to define the attributes. 

24. (Original) The computer readable medium of claim 22, wherein the executable program 
instructions further: 

allow a user to create new attributes; and 
allow the user to define the new attributes. 
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